Recently, a new generation of cell phones has been introduced that include provisions for Internet connectivity and “micro-browsers.” Using this class of device, the cell phone user can directly access content on the World Wide Web, receive email, be notified of changes in “subscribed information” such as sports scores or stock prices, etc.
The constraints imposed on a “micro-browser” in a cell phone environment pose a unique problem for both the information provider as well as the user retrieving the information. The development of the Wireless Application Protocol (“WAP”) specification was specifically designed to address a number of fundamental differences between classic Internet and Web-based services and services on a wireless data network. These issues included the differences in needs and expectations as well as differences imposed by the device. That is, wireless devices will generally have less powerful CPU's, less memory and smaller displays than conventional computers. Wireless devices may have very different input devices. Wireless devices other than cell phones may be used that have very different capabilities. All of these issues have been addressed in the WAP specification and architecture. In particular, the WAP system is in no way restricted to cell phones—integration into other devices with wireless connectivity (e.g. the PALM PILOT personal digital assistant) was clearly anticipated. Thus, although this application will generally refer specifically to cell phones, anything described in that context would also apply to any other comparable wireless device, such as a Personal Digital Assistant (“PDA”).
FIG. 1 outlines the basic WAP architecture. Wireless devices are not directly “on the Internet” in the same sense as traditional computers. The fact that devices roam around, as well as the sheer number of devices expected to be deployed, discourage a solution in which each wireless device has its own IP address and communicates directly. In addition, the standard Internet protocols require a fair amount of overhead, which poses a problem on a channel with limited bandwidth. As a result, a new set of wireless protocols was developed. These include the Wireless Session Protocol (“WSP”) and the Wireless Datagram Protocol (“WDP”) which parallel the function of the TCP/IP and UDP Internet protocols. Wireless Telephone Application (“WTA”) Servers “speak” these protocols natively, and can be directly accessed by wireless devices.
While for certain applications the requirement of a new class of server is acceptable, restricting wireless devices to this class of server would not adequately leverage the huge embedded base of Internet equipment. As such, the architecture includes WAP proxies, which serve as a bridge between the wireless network and the standard Internet. When a digital device attempts to access a resource via a standard URL, this request is passed to the WAP Proxy using wireless protocols. The WAP Proxy reformats this request into a standard HTTP 1.1 query, retrieves the content from the standard Web Server, and then passes the result back to the wireless device using the wireless protocol. Using this system, wireless devices can access any server on the Internet.
A web site that natively “understood” wireless devices would generally return content in the new Wireless Markup Language (WML), or possibly in the older Handheld Device Markup Language (HDML). Recognizing that achieving deployment of a second, parallel coding standard for documents might slow the penetration of the WAP technology, the WAP Architecture also includes provisions for filters that could translate standard HTML into WML automatically. These filters can be integrated into the WAP Proxy itself, or can exist between the web server and the WAP Proxy. This would, at least in theory, allow a wireless user to access any existing content on the web, even if the web site was not specifically designed for access by devices of this class.
A system and method for utilizing a link code or linkage code to cause a client computer to automatically access a web resource is disclosed in copending U.S. patent application Ser. No. 09/543,178, filed on Apr. 5, 2000 and incorporated by reference herein. In the system described therein, the link code is a bar code that is scanned by a bar code scanner and input into a client software program that uses the decoded link code to request a URL template from an external server computer. The server takes the link code, returns the URL template, and the link client program assembles the URL using other data at the client. The URL is passed to a web browser, which then retrieves the web resource. This process may also be performed by manually entering a text string associated with the code, such as by entering a UPC number found at the bottom of a typical UPC barcode. This is a powerful way of utilizing a general purpose computer to automatically access a web resource without having to type in a lengthy URL.
It is noted that the system described above relies on the use of a client program running on the client computing device for obtaining, assembling, and then providing the URL to the web browser program. In general purpose personal computers, loading and running of such a client program is of course a typical and easily-done process. It would be desirable, however, to use this content retrieval technology with a client device such as a web-enabled cell phone, in which the use of add-on programs such as the linkage client is not easily accomplished. That is, with the proliferation of web-enabled cell phones and the like, it would be desirable to enable such devices to use such content retrieval methodologies without requiring adaptation of the software or firmware already present on such devices. One aspect of the invention described herein is thus a server-based URL assembly/retrieval methodology that requires no modification to existing web-enabled devices such as web-enabled cell phones or internet kiosks.
Another problem encountered by utilization of web-enabled cell phones for Internet access is that such devices have unique display capabilities. That is, one cannot simply take any standard HTML web page and display it on a microbrowser or other such device. Thus, it is desired to be able to use the same linkage code in order to provide different types of content to different types of display devices. That is, it is desired to be able to format the content retrieved differently as a function of the device on which it will be displayed. As a result, a user entering a link code with a web-enabled cell phone will be automatically provided with WML or HDML content appropriate for display on that cell phone, while another user entering the same linkage code into a desktop computer will be provided with standard HTML content suitable for display on a large screen.
Although web-enabled cell phones can access web pages using the appropriate linkage code technology, one further problem is that much of the original content won't be displayable in the cell phone, since it will be in the form of big HTML pages. Alternatively, a user may be preoccupied and may simple wish to store a linkage code for subsequent retrieval. Therefore, it would be desirable to use the cell phone as a linkage code access device, without retrieving the associated content, but just for acquiring the linkage codes and uploading them to a code list server for later access by the user at a PC running the appropriate software.